领域驱动设计：掌握限界上下文以实现可扩展软件

领域驱动设计（DDD）是一种通过关注核心领域来应对复杂软件项目的强大方法。DDD的核心在于限界上下文的概念。理解并有效应用限界上下文对于构建可扩展、可维护且最终成功的软件系统至关重要。本综合指南将深入探讨限界上下文的复杂性，并探讨所涉及的战略和战术模式。

什么是限界上下文？

限界上下文是软件系统中的语义边界，它定义了特定领域模型的可适用性。将其视为一个清晰定义的范围，其中特定术语和概念具有一致且无歧义的含义。在限界上下文内部，通用语言——开发人员和领域专家使用的共享词汇——是明确且一致的。在此边界之外，相同的术语可能具有不同的含义，或者根本不相关。

本质上，限界上下文承认，对于复杂的系统来说，创建单一的、整体的领域模型通常是不切实际的，甚至是不可行的。相反，DDD提倡将问题域分解为更小、更易于管理的上下文，每个上下文都有自己的模型和通用语言。这种分解有助于管理复杂性、改善协作，并允许更灵活和独立的开发。

为什么要使用限界上下文？

使用限界上下文可在软件开发中提供诸多好处：

• 降低复杂性：通过将大型域划分为更小、更易于管理的上下文，可以降低系统的整体复杂性。每个上下文都可以更轻松地理解和维护。
• 改善协作：限界上下文促进开发人员和领域专家之间的更好沟通。通用语言确保在特定上下文中每个人都使用相同的语言。
• 独立开发：团队可以独立地处理不同的限界上下文，而不会互相干扰。这允许更快的开发周期和更高的敏捷性。
• 灵活性和可扩展性：限界上下文使您能够独立地演进系统的不同部分。您可以根据各自的需求来扩展特定的上下文。
• 提高代码质量：在限界上下文内专注于特定领域可以带来更清晰、更易于维护的代码。
• 与业务保持一致：限界上下文通常与特定的业务能力或部门保持一致，从而更容易将软件与业务需求相匹配。

战略 DDD：识别限界上下文

识别限界上下文是 DDD 战略设计阶段的关键部分。它包括理解领域、识别关键业务能力以及定义每个上下文的边界。以下是分步方法：

1. 领域探索：首先彻底探索问题域。与领域专家交谈，查阅现有文档，并理解所涉及的不同业务流程。
2. 识别业务能力：识别软件系统需要支持的核心业务能力。这些能力代表了业务执行的基本功能。
3. 寻找语义边界：寻找术语含义发生变化或适用不同业务规则的区域。这些边界通常预示着潜在的限界上下文。
4. 考虑组织结构：公司的组织结构通常可以为潜在的限界上下文提供线索。不同的部门或团队可能负责领域内的不同区域。康威定律（Conway's Law）在此高度相关，该定律指出“设计系统的组织会受到限制，以至于它们产生的设计是其组织通信结构的副本”。
5. 绘制上下文映射图：创建上下文映射图来可视化系统中的不同限界上下文及其关系。此映射图将帮助您理解不同上下文如何相互交互。

示例：电子商务系统

考虑一个大型电子商务系统。它可能包含几个限界上下文，例如：

• 产品目录：负责管理产品信息、类别和属性。通用语言包括“产品”、“类别”、“SKU”和“属性”等术语。
• 订单管理：负责处理订单、管理发货和处理退货。通用语言包括“订单”、“发货”、“发票”和“付款”等术语。
• 客户管理：负责管理客户帐户、个人资料和偏好设置。通用语言包括“客户”、“地址”、“忠诚度计划”和“联系信息”等术语。
• 库存管理：负责跟踪库存水平和管理库存地点。通用语言包括“库存水平”、“地点”、“重新订购点”和“供应商”等术语。
• 付款处理：负责安全地处理付款和处理退款。通用语言包括“交易”、“授权”、“结算”和“卡详细信息”等术语。
• 推荐引擎：负责根据客户的浏览历史和购买行为为其提供产品推荐。通用语言包括“推荐”、“算法”、“用户配置文件”和“产品亲密度”等术语。

这些限界上下文中的每一个都有自己的模型和通用语言。例如，“产品”一词在“产品目录”和“订单管理”上下文中可能具有不同的含义。在“产品目录”中，它可能指产品的详细规格，而在“订单管理”中，它可能仅指所购买的商品。

上下文映射图：可视化限界上下文之间的关系

上下文映射图是一种可视化表示系统中不同限界上下文及其关系的图表。它是理解不同上下文如何交互并就集成策略做出明智决策的关键工具。上下文映射图不深入探讨每个上下文的内部细节，而是侧重于它们之间的交互。

上下文映射图通常使用不同的符号来表示限界上下文之间不同类型的关系。这些关系通常被称为集成模式。

战术 DDD：集成模式

一旦识别出限界上下文并创建了上下文映射图，就需要决定这些上下文将如何相互交互。这就是战术设计阶段发挥作用的地方。战术 DDD 侧重于连接限界上下文时将使用的具体集成模式。

以下是一些常见的集成模式：

• 共享内核：两个或多个限界上下文共享一个通用的模型或代码。这是一种有风险的模式，因为共享内核中的更改会影响所有依赖它的上下文。请谨慎使用此模式，并且仅在共享模型稳定且定义明确时使用。例如，金融机构中的多个服务可以共享一个核心库来进行货币计算。
• 客户-供应商：一个限界上下文（客户）依赖于另一个限界上下文（供应商）。客户积极塑造供应商的模型以满足其需求。当一个上下文强烈需要影响另一个上下文时，此模式很有用。营销活动管理系统（客户）可能会严重影响客户数据平台（供应商）的开发。
• 遵从者：一个限界上下文（遵从者）仅使用另一个限界上下文（上游）的模型。遵从者对上游模型没有影响，必须适应其更改。在与遗留系统或第三方服务集成时，通常会使用此模式。小型销售应用程序可能只需遵循大型、成熟的 CRM 系统提供的数据模型。
• 反腐败层（ACL）：一个抽象层位于两个限界上下文之间，在它们的模型之间进行转换。此模式可保护下游上下文免受上游上下文更改的影响。在处理遗留系统或无法控制的第三方服务时，这是关键模式。例如，在与遗留薪资系统集成时，ACL 可以将遗留数据格式转换为与人力资源系统兼容的格式。
• 分道扬镳：两个限界上下文之间没有关系。它们是完全独立的，可以独立演进。当两个上下文根本不同且无需交互时，此模式很有用。员工的内部费用跟踪系统可能与面向公众的电子商务平台完全分开。
• 开放主机服务（OHS）：一个限界上下文发布一个定义良好的 API，其他上下文可以使用该 API 来访问其功能。此模式促进了松耦合，并允许更灵活的集成。API 的设计应考虑到消费者的需求。支付网关服务（OHS）公开了一个标准化的 API，各种电子商务平台可以使用该 API 来处理付款。
• 发布语言：开放主机服务使用定义良好且文档齐全的语言（例如 XML、JSON）与其他上下文进行通信。这确保了互操作性并降低了误解的风险。此模式通常与开放主机服务模式结合使用。供应链管理系统通过使用 JSON Schema 的 REST API 公开数据，以确保清晰一致的数据交换。

选择正确的集成模式

集成模式的选择取决于多个因素，包括限界上下文之间的关系、其模型的稳定性以及您对每个上下文的控制程度。在做出决定之前，仔细考虑每种模式的权衡非常重要。

常见陷阱和反模式

虽然限界上下文可能非常有益，但也有一些常见的陷阱需要避免：

• 混乱的泥球：未能正确定义限界上下文，最终导致一个难以理解和维护的整体系统。这与 DDD 的目标背道而驰。
• 意外的复杂性：通过创建过多的限界上下文或选择不当的集成模式来引入不必要的复杂性。
• 过早优化：在完全理解领域和限界上下文之间的关系之前，过早地尝试优化系统。
• 忽视康威定律：未能使限界上下文与公司的组织结构保持一致，导致沟通和协调问题。
• 过度依赖共享内核：过于频繁地使用共享内核模式，导致紧耦合和灵活性降低。

限界上下文与微服务

限界上下文通常用作设计微服务的起点。每个限界上下文都可以实现为一个单独的微服务，从而实现独立的开发、部署和扩展。但是，需要注意的是，限界上下文不一定非要实现为微服务。它也可以作为大型应用程序中的一个模块来实现。

在将限界上下文与微服务结合使用时，仔细考虑服务之间的通信非常重要。常见的通信模式包括 REST API、消息队列和事件驱动架构。

全球实践范例

限界上下文的应用具有普遍性，但具体细节将根据行业和上下文而有所不同。

• 全球物流：一家跨国物流公司可能拥有独立的限界上下文，用于*货物跟踪*（处理实时位置更新）、*海关清关*（处理国际法规和文件）和*仓库管理*（优化存储和库存）。所跟踪的“物品”在每个上下文中都有非常不同的表示。
• 国际银行业务：一家全球性银行可以使用限界上下文来处理*零售银行业务*（管理个人客户账户）、*商业银行业务*（处理商业贷款和交易）和*投资银行业务*（处理证券和交易）。“客户”和“账户”的定义在这些领域之间差异很大，反映了不同的法规和业务需求。
• 多语言内容管理：一家全球性新闻机构可以拥有独立的限界上下文来*内容创作*（撰写和编辑文章）、*翻译管理*（处理不同语言的本地化）和*出版*（通过各种渠道分发内容）。“文章”的概念在被撰写、翻译或发布时具有不同的属性。

结论

限界上下文是领域驱动设计中的基本概念。通过有效理解和应用限界上下文，您可以构建复杂、可扩展且可维护的软件系统，这些系统与业务需求保持一致。请记住仔细考虑限界上下文之间的关系，并选择合适的集成模式。避免常见的陷阱和反模式，您将朝着掌握领域驱动设计迈出坚实的步伐。

可操作的见解

1. 从小处着手：不要试图一次性定义所有限界上下文。从最重要的大领域开始，并随着学习的深入进行迭代。
2. 与领域专家合作：在整个过程中让领域专家参与进来，以确保您的限界上下文准确地反映业务领域。
3. 可视化您的上下文映射图：使用上下文映射图将限界上下文之间的关系传达给开发团队和利益相关者。
4. 持续重构：随着对领域理解的演变，不要害怕重构限界上下文。
5. 拥抱变化：限界上下文不是一成不变的。它们应该适应不断变化的业务需求和技术进步。